1. Field of the Invention
The present invention relates to devices and methods for testing the functionality of components of a computer system and, more particularly, to object-oriented design methodologies for testing the functionality of bus bridge implementations for use with multi-master computer systems.
2. Description of the Related Art
Reliability and efficiency of any computer system depend in part upon the system complexity as well as upon the measures taken to minimize or prevent occurrences of faulty operations. Various modern-day mechanisms, including parallel processing, high-speed microprocessors, RISC (Reduced Instruction Set Computer) architectures and on-board hardware redundancies allow faster system performance and throughput while increasing system reliability. Particularly in relatively complex, high performance systems, it is important to provide means for testing the proper functionality of the system and to provide fault corrections both upon the design and manufacture of the various system components, and during system operation.
Monitoring and verifying the functionality of a particular design of a computer system component through software means has undoubtedly proven to be a reasonable alternative to manual verification methodologies and to purely hardware test systems. The use of software for system verification is not, however, entirely without its attendant costs. The time required to perform various tests may be lengthy. Furthermore, and perhaps of greater significance, is the fact that the overall accuracy or coverage of the tests may be limited, thus leading to indications of false failures or to undetected defects.
Corrupted bus cycles in a system can be a major source of loss of reliability or efficiency. It is not uncommon for bus cycles initiated by various bus masters to not reach their desired destinations, or to otherwise be corrupted. This can result from various factors, such as improper hardware design, faults in bus lines, physical or functional defects in chip or board fabrications, and faulty execution in system software routines. A key component in many computer systems which manages bus cycles is a bus bridge. Verification systems have thus been developed to verify the design of a bus bridge, either upon its initial design in a hardware description language such as Verilog or following actual hardware implementation.
Historically, verification systems for bus bridge designs have proven inadequate to preserve the right data and right address for every bus cycle in a system involving multiple transactions. One prior art method for testing the functionality of a bus bridge employs reference counts associated with each address being written to memory. The CPU decrements the count upon completion of the write operation. Although every address transaction is given its individual count, this method may fail to preserve address counts in bus bridge implementations that employ memory remapping.
False failures may also be caused by byte merging, i.e. merging of transactions to adjacent or contiguous memory addresses. In this scheme, for example, four cycles into the bus bridge may only create only one cycle out. This may result in the bus bridge erroneously incrementing in multiple counts without decrementing consistent with the merged transactions, thus leading to false indications of error.
Byte collapsing is another source of error in bus transaction verification schemes. In this approach, more than one write cycle to the same memory address may result in only the most recent data being preserved. In other words, the earlier data to the particular address may be overwritten by a later cycle. Here, as in byte merging, the bus bridge testing methodology may fail to preserve the correct address count.
Yet another source of error in previous bus transaction verification schemes is an occurrence of an aborted bus transaction. When cycles to addresses are aborted without being completed, failures occur if the system does not properly track and account for the aborted cycles.
Most transaction testing methodologies for bus bridges treat computer systems as address-based rather than cycle-based. Typical approaches to address and data verification do not take into account the internal states of a machine, nor any other internal states associated with a memory or other system cycles. Critical cycle oriented information may not be considered, causing inadequate verification. When critical bus cycle information is discarded, resolution of later arising cycle conflicts may not be completely sound.
Furthermore, a bus bridge verification requires insuring that each bus attached to the bridge operates with a proper timing and protocol. This verification is typically accomplished using bus monitors. Bus monitors are modules that monitor the signals on a given bus and flag improper operation. Bus monitors are typically constructed in the same hardware design language as the bus bridge being simulated. Also, bus monitors may typically perform their verification tasks during the simulation.
In some cases, it is necessary for a bus monitor to be aware of internal bus bridge configuration register values. For example, a DRAM memory bus monitor should verify proper RAS and CAS pulse width values and DRAM refresh intervals. The values for these timing intervals are set using configuration registers in the bus bridge. Hence, in order to verify that the bus bridge operation is proper with respect to these configurable timing intervals, the bus monitor directly accesses the configuration register values using the actual net name of the configuration register in the actual bus bridge design.
This bus monitor dependence on the actual net name of a configuration register has one major disadvantage: the bus monitor is not portable across any designs where the net names are varied. A conversion of the net list that does not preserve net names--as for example, a conversion of an RTL (Register Transfer Logic) net list to a gate net list used for circuit layout--will also render the bus monitor inoperable.
Therefore, a bus bridge testing methodology and mechanism are needed to monitor the states of a bus bridge in a computer system to thereby determine proper functionality. Knowledge of the bus bridge states will allow better determination of failures. It is also desirable to have a verification system that monitors and records bus bridge performance, and verifies correct behavior of a bus bridge cache master.
Finally, it is further desirable to have a bus bridge verification methodology where timing and other functionality of a system bus attached to the bus bridge can be verified in a manner independent of the bus bridge's hardware description language representation. Additionally, a bus bridge verification system is desirable that allows bus monitors to be portable across various bus bridge designs and their revisions.